Computer networks support data communications using layered protocols. The commonly used TCP/IP protocols typically have layers of protocols for link, network, transport and application protocol. Efficiency of network communications is of particular concern for wireless or other limited bandwidth networks. Data units used by each of the many layers of protocols in a data communication system are required to carry a protocol header comprised of information used for the data communication system. In the prior art, protocol headers in one layer have contained redundant information as compared with protocol headers in another layer. Due to current protocol specifications for protocol headers among the protocol layers, protocol header information has become to be major percentage of the data communication traffic. The actual data carried in the protocol and data units of a communication layer can often be small in comparison with information contained in the protocol header. While reducing the information contained in the protocol header is a conceptually simple solution to this transmission inefficiency, specifications of each protocol provide for a fixed amount of information in the protocol header and cannot be changed without substantial time and cooperation of the standards authorities. The substantial effect of protocol header traffic is particularly apparent for Internet Protocol-based telephony. Voice communications on IP networks are typically carried out under an RTP protocol. A standards organization for the 3GPP protocol has authoritatively defined data packet structure for data transmission of voice traffic (IP Multimedia Subsystems—IMS) so that the voice data can occupy just 12 bytes of a 112 byte IP packet payload. The following is an example of a protocol header for the IPsec protocol packets, identifying other well known packet fields for this packet:
HeaderSizeCodec Payload12AMR Payload TOC2RTP12Inner UDP8IP Inner20Total IPsec Payload54Ipsec ESP Fields30Outer UDP (RFC 3948)8IP Outer20Total IP Packet Size (B)112
An obvious inefficiency of transmitting a payload that is small compared to the total IP packet size has led to the development of only a few protocol compression solutions.
A header compression method has been established under IETF standards RFC 1108 or RFC 2508, but these are not suitable for networks that carry voice communications. Another such standard, RFC 1108 is directed to the complexities of TCP traffic and does not provide support for low latency communications. The techniques described in yet another standard, RFC 2508, provide for compression by calculating differences between successive packets. If a packet is lost, the compression algorithms must retransmit and reset the state of the compression. This causes unacceptable latencies and data voice corruption. The Robust Header Compression (ROHC—RFC 3095) specification (described in U.S. Pat. No. 6,608,841) also use a header difference mechanism. Yet another standard, RFC 3095, provides improvements in environments with packet loss, but still uses a difference based dynamic compression.
Existing header compression solutions do not support encryption. Encryption of communications with a protocol like the IETF defined Encapsulating Security Protocol (RFC 2406) encrypts all of the contained headers making them uncompressible, and thereby unavailable for use until decrypted. Compression applied to the protocols within the ESP packet would result in a minor benefit to packet size but would still result in protocol and data unit redundancy among the layers' protocol headers and the potential for compression in the ESP protocol.
Some prior art protocol compression techniques require that only the information that is different on each packet is identified. These differences can vary from packet to packet and require the use of difference fields that are type/length/value delimited. These differences are often predictable and this predictability is not considered in the existing designs making them considerably more complex than is necessary. Specifically, a preferred traffic method for voice communications has a simple profile. Complex techniques for more stateful protocols that support retransmission are not required and more simple template based mechanism can be used. More efficient implementations are possible when the protocols used for carrying data can be constrained to profiles that do not support retransmission or fragmentation. In this case, and sequences numbers carried in the protocol layers will always be synchronized. As a lower layer protocols sequence number increases, the higher level protocols sequence number will be incremented identically. In this manner, given an appropriate template for the header compression that describes which fields need to be left out, the sequence numbers can be directly reconstructed.
These templates can be even more efficient if they use knowledge from lower uncompressed layers (like ESP). The ESP protocol provides sequence numbers, data confidentiality (encryption) and data integrity (cryptographic checksum). The ESP sequence number can be used to directly determine the sequence number of a upper layer protocol that is uniquely bound to the ESP protocols security association. The services provided by ESP data integrity can be used to completely replace any checksum carried internal to the ESP packet. Specifically UDP checksums are not required. There is no need to carry this field.
Current specifications for 3GPP and IETF are easily obtained.
3GPP Specifications may be obtained at http://www.3gpp.org/specs/numbering.htm. The following are a selection of those specifications:                TS 21.905 Vocabulary for 3GPP Specifications        TS 22.340 IMS Messaging; Stage 1        TS 23.002 Network Architecture        TS 23.218 IMS session handling; IM call model; Stage 2        TS 23.221 Architectural Requirements        TS 23.228 IMS stage 2        TS 23.234 WLAN interworking        TS 24.228 Signalling flows for the IMS call control based on SIP and SDP; Stage 3        TS 24.229 IMS call control protocol based on SIP and SDP; Stage 3        TS 29.162 Interworking between the IMS and IP networks        TS 33.102 3G security; Security architecture        TS 33.203 3G security; Access security for IP-based services        TS 33.210 3G security; Network Domain Security (NDS); IP network layer security        TR 33.978 Security aspects of early IP Multimedia Subsystem (IMS)        
IETF Specifications are also well known in the art. The following a current list thereof:                RFC 2327 Session Description Protocol (SDP)        RFC 2748 Common Open Policy Server protocol (COPS)        RFC 2782 a DNS RR for specifying the location of services (SRV)        RFC 2806 URLs for telephone calls (TEL)        RFC 2915 the naming authority pointer DNS resource record (NAPTR)        RFC 2916 E.164 number and DNS        RFC 3087 Control of Service Context using SIP Request-URI RFC 3261 Session Initiation Protocol (SIP)        RFC 3262 reliability of provisional responses (PRACK)        RFC 3263 locating SIP servers        RFC 3264 an offer/answer model with the Session Description Protocol        RFC 3265 SIP-Specific Event Notification        RFC 3310 HTTP Digest Authentication using Authentication and Key Agreement (AKA)        RFC 3311 update method        RFC 3312 integration of resource management and SIP        RFC 3319 DHCPv6 options for SIP servers        RFC 3320 signalling compression (SigComp)        RFC 3323 a privacy mechanism for SIP        RFC 3324 short term requirements for network asserted identity        RFC 3325 private extensions to SIP for asserted identity within trusted networks        RFC 3326 the reason header field        RFC 3327 extension header field for registering non-adjacent contacts (path header)        RFC 3329 security mechanism agreement        RFC 3420 Internet Media Type message/sipfrag        RFC 3428 SIP Extension for Instant Messaging        RFC 3455 private header extensions to SIP for 3GPP        RFC 3485 SIP and SDP static dictionary for signaling compression        RFC 3515 the SIP REFER method        RFC 3550 Real-time Transport Protocol (RTP)        RFC 3574 Transition Scenarios for 3GPP Networks        RFC 3588 DIAMETER base protocol        RFC 3589 DIAMETER command codes for 3GPP release 5 (informational)        RFC 3608 extension header field for service route discovery during registration        RFC 3665 SIP Basic Call Flow Examples        RFC 3680 SIP event package for registrations        RFC 3725 best current practices for Third Party Call Control (3 pcc) in SIP        RFC 3824 using E164 numbers with SIP        RFC 3840 indicating user Agent Capabilities in SIP        RFC 3841 caller preferences for SIP        RFC 3842 SIP event package for message waiting indication and summary        RFC 3856 SIP event package for presence        RFC 3891 the SIP Replaces Header        RFC 3903 SIP Extension for Event State Publication        RFC 3911 the SIP Join Header        RFC 4028 session timers in SIP        RFC 4235 an INVITE-Initiated dialog event package for SIP        RFC 4475 Session Initiation Protocol (SIP) Torture Test Messages        
There is a need for a system of communication via packet networks where protocol processing, compression and encryption is made more efficient by adaptation of coordination of sequence numbers between layer protocols and the integration of encryption protocol processing into the compression and decompression process.